%%This is a very basic article template.
%%There is just one section and two subsections.
\documentclass{book}
\usepackage{tipa}
\usepackage[english]{babel}
\usepackage{graphicx}
\usepackage[utf8x]{inputenc}
\usepackage{listings}
\usepackage{array}

\include{commandsDefinitions}

\begin{document}

\title{Kaboom\\ Kaboom: Awesomeness By Object Oriented Models}
\author{Massimo Bono, Simone Brognoli}
\date{\today}
\maketitle

\tableofcontents

\chapter{Introduzione}

\chapter{Potenzialità di Yaoola}

\chapter{Concetti interessanti}

\section{Commenti}

In \emph{Yaoola} i commenti sono C-like ossia possono essere di due tipi:
\begin{itemize}
  \item commenti su una sola linea, identificati da ``//'';
  \item commenti su più linee inizianti da ``/*'' e terminanti da ``*/'';
\end{itemize}

\section{Ereditarietà}

In \emph{Yaoola} l'ereditare risorse (campi o metodi) deve essere vista come una decorazione dell'oggetto base. Per esempio ipotizziamo che esistano
due classi A e B, dove B è una classe figlia di A. In questo caso tutti le risorse etichettate con \emph{children} o con \emph{all} saranno
accessibili anche dalla classe B. Questa accessibili deve essere vista come una decorazione, come quello che accade per il pattern Decoration.\\
La questione delle ereditarietà si fa invece più complessa in caso di ereditarietà multipla. Supponiamo di avere 4 classi:
\begin{itemize}
  \item classe Ancestor;
  \item classe Parent1 figlia di Ancestor;
  \item classe Parent2 figlia di Ancestor;
  \item classe Child figlia di Parent1 e Parent2;
\end{itemize}
Supponiamo poi che Ancestor detenga una variabile \emph{name} leggibile e scrivibile dai figli; se è così allora anche Parent1 e Parent2 avranno questa variabile.
Se continuiamo la catena di ereditarietà allora Child possiederà due variabili chiamate entrambe \emph{name}: una ereditata da Parent1 e l'altra ereditata da Parent2.
In questo scenario (figura \ref{fig:ereditarieta02}) sono attuabili diverse soluzioni:
\begin{enumerate}
  \item eliminare una variabile: possiamo affermare che se una classe possiede due variabili con lo stesso nome viene presa solo la prima mentre l'altra viene scartata.
  	Questa soluzione non è ideale; infatti se Parent1 e Parent2 avessero entrambe due variabili chiamate \emph{surname} una di tipo String mentre l'altra di tipo Integer
  	dovremmo porci il problema circa quale variabile scartare. e se dopo una di queste variabili viene usata (come altamente probabile) all'interno di un metodo? Questo
  	approccio è da scartare.
  \item differerenziare le diverse variabili. L'unico modo per distinguere le due variabili \emph{surname} è indicare la loro provenienza, ossia scrivere:
  \begin{verbatim}
  	this.Parent1.surname=(string)this.Parent2.surname;
  \end{verbatim}
  \item ritornare errore: se il compilatore si accorge che in una qualunque classe esistono due variabili con lo stesso nome (che siano dichiarate nella stessa classe o ereditate
  non fa differenza) il compilatore ritorna un errore.
\end{enumerate}
\emph{Yaoola} utilizza la terza possibilità, il ritorno di un errore: infatti entrare in scenari come questi significa molto probabilmente aver fatto
una pessima progettazione del codice.

\begin{figure}[h]
	\centering
	\label{fig:ereditarieta02}
	\caption{problemi nell'ereditarietà multipla}
	\includegraphics[scale=0.5]{../grp/ereditarieta02.jpg}
\end{figure}

\section{Overriding e polimorfismo}
TODO

\section{Campi a valore e Campi ad indirizzo}
Un campo di una classe può essere di due tipi:
\begin{itemize}
  \item a valore (\emph{value}): indica un oggetto fisico ben preciso;
  \item a indirizzo (\emph{reference}): indica un puntatore ad un altro oggetto, che può essere a sua volta un puntatore o un oggetto fisico.
\end{itemize}
Perché realizzare una distinzione di questo tipo? Guardiamo un esempio: la classe Studente avrà come campi
\begin{itemize}
  \item nome di tipo String;
  \item cognome di tipo String;
  \item risultati di tipo array di RisultatiEsame;
\end{itemize}
la classe RisultatiEsame, d'altra parte, avrà come campi:
\begin{itemize}
  \item esame di tipo Esame;
  \item voto di tipo Float;
\end{itemize}
ora, \emph{risultati} sara' dichiarato come \emph{a valore} in quanto ogni studente deve avere un solo risultato per ogni esame. Invece nella
classe \textbf{RisultatiEsame} il campo \emph{esame} sara' di tipo \emph{a indirizzo}: questo perché se ci sono 200 studenti non ha senso
creare per ogni studente che ha sostenuto l'esame di Compilatori un oggetto rappresentante l'esame Compilatori. è molto più logico crearne
uno e poi per ogni RisultatoEsame creare un puntatore all'oggetto.
\begin{figure}[h]
	\centering
	\label{fig:ereditarieta02}
	\caption{problemi nell'ereditarietà multipla}
	\includegraphics[scale=0.5]{../grp/dichiarazioneCampi.jpg}
\end{figure}
\section{funzioni}

Dal punto di vista degli input le funzioni possono avere due tipi diversi di input:
\begin{itemize}
  \item \textbf{copy}: viene passata solo una copia della variaible attuale in modod da implementare il passaggio per valore;
  \item \textbf{real}: viene passata la variabile originale in modo da implementare il passaggio per indirizzo;
\end{itemize}

La differenza con il C e' che qui il programmatore non vede veramente i puntatori, ma ne sfrutta comunque le più semplici proprietà;
in questo modo è possibile realizzare la funzione \emph{swap}, funzione che in Java non è possibile realizzare in alcun modo semplice.\\
Per quanto riguarda la variabile di ritorno di una funzione anch'essa può essere di due tipi:
\begin{itemize}
  \item \textbf{copy}: rappresneta una copia della variabile da ritornare all'interno della funzione; se, per esempio, vogliamo implementare un MazeFactory, 
  	è possibile farlo attraverso questo modo di passare le variabili di ritorno:
  	\begin{lstlisting}
static function copy Maze buildMaze(copy int type){
	if (type==0){
		return mazelist[0];
 	}
} 
  	\end{lstlisting} 
  \item \textbf{real}: rappresenta la variabile vera e propria ritornata dalla funzione; se, per esempio, abbiamo una griglia con degli elementi e vogliamo implementare un get possiamo farlo usando:
  	\begin{lstlisting}
function real Element getElementByPosition(copy int x,copy int y){
	return matrix[x][y];
}
  	\end{lstlisting} 
\end{itemize}

\section{Dichiarazione di variabili locali}

Una variabile locale puo' essere inizializzata solo secondo la modalità \emph{value}. Una variabile locale può tuttavia comunque essere di due tipi:
\begin{itemize}
  \item una variabile semplice, ossia avere uno solo tra i tipo string, int, char e bool;
  \item una classe.
\end{itemize}
Una variabile locale non può essere di tipo \emph{reference} in quanto questi particolari tipi di variabili vengono usati solo nei campi di classe per risparmiare spazio in progetti
in cui le interazioni tra classi sono abbastanza complesse. Inoltre qualunque cosa in \emph{Yaoola} ritorna un oggetto concreto, sia esso una copia di un originale o l'originale stesso:
in altre parole non avviene mai il caso in cui dobbiamo incamerare un indirizzo.

\section{permessi di lettura e di scrittura}

In \emph{Yaoola} una classe è vista come un contenitore di risorse. Tali risorse non sono accessibili a qualunque classe ma solo a classi
che appartengono a particolari gruppi. In generale per ogni risorsa sono da specificare due tipi distinti di accesso:
\begin{enumerate}
  \item accesso in lettura (\readable \by): indica chi può leggere la data risorsa. Leggerla significa poterla utilizzare in una qualunque espressione.
  \item accesso in scrittura (\writeable \by): indica chi può modificare la data risorsa;
\end{enumerate}

I due accessi variano a seconda di quale risorsa stiamo parlando. Cosa è possibile fare a seconda dei permessi e della risorsa è brevemente riassunto
in tabella \ref{tab:accessi}; notare che avere gli accessi in scrittura per una costante non da privilegi aggiuntivi rispetto a non averne l'accesso.\\

\begin{table}[h]
	\centering
	\label{tab:accessi}
	\begin{tabular}{|c|c|c|}
		\hline
			Tipo di risorsa	&	accesso in lettura	&	accesso in scrittura\\
		\hline
			classe		&	possibile usarla nel proprio programma	&	possibile usarla come padre\\
		\hline
			costante	&	possibile usarla in espressioni	&	-\\
		\hline
			variabile	&	possibile usarla in espressioni	&	possibile sovrascriverla\\
		\hline
			funzione	&	possibile usarla in espressioni	&	possibile fare overriding\\
		\hline
	\end{tabular}
	\caption{la tabella spiega cosa è possibile fare se si possiedono particolari privilegi di accesso con una particolare risorsa}
\end{table}

In \emph{Yaoola} ogni tipo di accesso di ogni risorsa può essere specificato da uno o più gruppi di accesso.
Tali gruppi vengono identificati dalle \emph{group-labels}: esse sono delle stringhe a cui vengono associate una serie di classi; tale stringa
viene scelta dal programmatore.
Ipotizzando che una classe A voglia accedere (in lettura o in scrittura) ad una risorsa b della classe B, affinché ciò sia possibile
la classe A deve appartenere ad almeno un gruppo di lettura della classe B ed ad almeno un gruppo (di lettura o scrittura) della risorsa b.
Implementativamente:
\begin{lstlisting}
class B readable by leggoclasse {
	int b readable by leggovariabile;
}
class A member of leggoclasse, leggovariabile{
	int a;
	function init(copy B oggettob) readable by all writeable by all{
		a=oggettob.b;
	}
}
\end{lstlisting}

Esistono inoltre particolari gruppi, ossia delle label speciali per indicare un set particolare di classi:
\begin{enumerate}
  \item \all: indica qualunque classe;
  \item \onlyme: indica solo la classe corrente;
  \item \children: indica solo la classe corrente e qualunque suo figlio (diretto o indiretto);
\end{enumerate}
Ora il problema principale è: dove vengono create le \emph{group-labels} (nell'esempio ``leggoclasse'' e ``leggovariabile'')? La risposta
è in un file (che deve essere importato) contenente le labels. Tali labels possono essere di due tipi:
\begin{itemize}
  \item \public il gruppo indicato dall'etichetta può essere in qualunque momento allargato a nuove classi;
  \item \package il gruppo indicato dall'etichetta è utilizzato internamente da un pacchetto di classi e quindi non può essere ulteriormente allargato; 
\end{itemize}

\section{cosa à \classID?}
\classID è o un semplice \id oppure è la reserved word \this. In certi casi infatti (come ad esempio la \procedureCallStat) anche \this 
può sostituire il normale ID. Il controllo che il programmatore non scriva frasi del tipo:
\begin{lstlisting}
this.this.a.this=5;
\end{lstlisting}
non è incluso nella grammatica, ma viene delegato a fasi successive: questo per evitare che la grammatica si appesantisca troppo.

\section{Dichiarazione e inizializzazione di un array}

In \emph{Yaoola} un array viene dichiarato secondo una notazione C-like:
\begin{lstlisting}
Studente[] database;
\end{lstlisting}
Tuttavia la sua notazione avviene come se fosse una classe, ossia tramite il comando new:
\begin{lstlisting}
database=new Studente[10];
\end{lstlisting}
Tra parensentesi viene inserito il numero di slot da allocare in memoria, indicanti la lunghezza dell'array.
In caso si tratti di un array multidimensionale, l'inizializzazione sarà del tipo:
\begin{lstlisting}
database=new Studente[10][5];
\end{lstlisting}

\section{regole di associatività}

In \emph{Yaoola} una espressione è composta da fattori ed operatori. Gli operatori possono essere di vario tipo:
\begin{itemize}
  \item matematica: somma, sottrazione, moltiplicazione, divisione, resto, opposto;
  \item logica: and, or, not;
  \item comparativa: uguale, diverso, maggiore uguale, minore uguale, minore stretto, maggiore stretto;
  \item di linguaggio: new;
\end{itemize} 

Ogni operatore può essere unario, ossia richiedere un unico termine, oppure binario, ossia richiederne due. Gli operatori binari 
hanno generalmente diverse associatività e diverse precedenze; per esempio la moltiplicazione viene eseguita \emph{prima} della somma.
La priorità e la relativa associatività degli operatori è mostrata in tabella \ref{tab:assoc}: 
in essa maggiore è la priorità, più in alto l'operatore sarà mostrato in tabella.

\begin{table}[h]
	\centering
	\label{tab:assoc}
	\begin{tabular}{|c|c|}
		\hline 
			operazioni	&	associatività\\
		\hline
			$==$ $!$$=$ $>=$ $<=$ $>$ $<$	&	nessuna\\
		\hline
			\&\& {\textpipe}{\textpipe}	&	sinistra\\
		\hline
			* / \%	&	sinistra\\
		\hline
			+ -	&	sinistra\\
		\hline
	\end{tabular}
\end{table}

Per quanto concerne invece i fattori, essi possono essere:
\begin{itemize}
  \item variabili: ossia variabili semplici, ossia variabili dichiarate come \emph{char} o \emph{int}, oppure campi di classe;
  \item costanti: ossia elementi scritti nel codice sorgente stesso: per esempio possono essere numeri o caratteri;
  \item espressioni tra parentesi;
  \item chiamate a funzione;
  \item inizializzazioni di classe (tramite il comando \textbf{new});
\end{itemize}

\section{Symbol table}

In \emph{Kaboom} esiste una \textbf{symbol table} racchiudente tutte le risorse
disponibili. Le risorse disponibili possono provenire da 2 locazioni:
\begin{enumerate}
  \item da pacchetti richiesti precompilati;
  \item dal pacchetto che si sta creando; 
\end{enumerate}

La symbol table di \emph{Kaboom} in linea generale tiene traccia delle label disponibili e delle classi:
\begin{enumerate}
  \item le label disponibili: rientrano in questa categoria le label pubbliche offerte dai pacchetti esterni richiesti;
  \item le label intrapacchetto: rientrano in questa categoria le label pubbliche e di package del pacchetto in corso di creazione;
  \item le classi disponibili: rientrano in questa categoria le classi con almeno una risorsa disponibile provenienti dai pacchetti esterni;
  \item la classi intrapacchetto: rientrano in questa categoria le classi in corso di creazione;
\end{enumerate}

Il compilatore, al momento della compilazione, prende da particolari file salvati nel pacchetto la symbol table del pacchetto stesso
e la unisce con quella del pacchetto (o classe) in creazione. Quello che ottiene è una struttura \textbf{piatta}: ciò significa che se due classi
(o label) possiedono lo stesso nominativo, viene generato un errore. I pacchetti sono dunque un'introduzione necessaria in quanto durante 
la compilazione è richiesta la symbol table del package richiesto.\\

A livello implementativo la symbol table sono in realtà 2 strutture dati:
\begin{itemize}
  \item \emph{label table} ossia una tabella contenente tutte le label dichiarate; essa contiene tutte le label ricavate dai pacchetti TNT più le label
  	dichiarate all'interno del pacchetto che si sta creando;
  \item \emph{class table} ossia una tabella contenente tutte le classi utilizzabili; essa contiene le classi dai pacchetti TNT che possiedono almeno
  	una risorsa utilizzabile più le classi dichiarate all'interno del pacchetto in creazione;
\end{itemize}

Entrambe queste tabelle si configurano come \textbf{hash tables} dove le chiavi sono per la \emph{label table} i nomi delle etichette mentre per
la \emph{class table} sono i nomi delle classi. Non esistono quindi identificatori particolari per questi 2 concetti.\\
Al momento sono stati trovati i seguenti possibili errori che potrebbero sorgere durante il merging tra le table dei pacchetti TNT
 e quella in corso di preparazione:
\begin{enumerate}
  \item una classe nel pacchetto in sviluppo e una in un pacchetto esterno possiedono lo stesso nome;
  \item una label nel pacchetto in sviluppo (di tipo \package o \public non fa differenza) e una in un pacchetto esterno possiedono lo stesso nome;
\end{enumerate}


Una \emph{label table} è semplicemente una tabella che contiene la seguente struttura:
\begin{itemize}
  \item name: nome della label;
  \item type: tipo della label;
\end{itemize}

il tipo di label (\public o \package) è presente perché il compilatore inserisce nella tabella sia le label dei pacchetti TNT esterni (che sono tutte public)
sia le label presenti nel pacchetto in sviluppo (che invece possono essere sia public che package). Al momento della compilazione, tuttavia, verrano
esportate \emph{solo} le label pubbliche del pacchetto corrente: quelle dei pacchetti esterni non verrano estratte in quanto costituirebbero una ridondanza.\\
Per quanto riguarda la class table essa è strutturata per contenere le varie classi.
Per esempio se l'intero codice sorgente (incluso ogni suo singolo require) utilizza le classi A,B e C allora nella symbol table
saranno contenute tutte le informazioni relative le classi A, B e C.\\

In linea generale quindi la \textbf{symbol table} contiene le informazioni relative a ciascuna classe. Le informazioni relative a ciascuna classe
possono essere divise in due tipi:
\begin{itemize}
  \item risorse: ossia variabili, costanti e metodi;
  \item informazioni generali: informazioni come se la classe è statica o astratta oppure i vari padri della classe stessa;
\end{itemize}

Per quanto riguarda le informazioni generali una classe di \emph{Kaboom} può avere:
\begin{enumerate}
  \item nome;
  \item staticità;
  \item astrazione;
  \item lista dei gruppi di cui fa parte: indica una lista di stringhe. Queste stringhe verrano poi cercate all'interno della \emph{label table}
  \item lista di classi che si configurano come padri per la classe;
  \item lista delle risorse disponibili;
\end{enumerate}

Per ogni risorsa invece sono disponibili queste informazioni:
\begin{enumerate}
  \item class: indica la classe della risorsa. Questa informazione serve per capire con che tipo di risorsa stiamo avendo a che fare (i.e. funzione, variabile, costante);
  \item name: indica il nome della risorsa stessa;
  \item oid: indica un identificatore di una risorsa; questo identificatore	viene utilizzato nell'intermediate code.TODO
  \item abstract: indica se questa risorsa è astratta;
  \item static: indica se questa risorsa è statica;
  \item readable: indica una lista di puntatori a stringa che sono contenute nella \emph{label table}.
  \item writeable: indica una lista di puntatori a stringa che sono contenute nella \emph{label table}.
  \item schema: indica il tipo della risorsa. Se stiamo parlando di una funzione indica il valore di ritorno della funzione. NULL se la funzione ritorna un void;
  \item local environment: indica un luogo in cui sono specificate le variavbili locali di una risorsa;
  \item vararg: indica il numero di parametri formali di una funzione;
  \item prototype: indica un luogo in cui sono specificati i parametri formali di una risorsa;
\end{enumerate}

\begin{table}
	\centering
	\label{tab:risorse}
	\begin{tabular}{|c|C{3cm}|C{3cm}|C{3cm}|}
		\hline
			nome informazione & variabile &	costante	&	funzione\\
		\hline
			class		&	indica che la risorsa è una variabile & indica che la risorsa è una costante & indica che la risorsa è una funzione\\
		\hline
			abstract	&	-	&	-	&	indica se la funzione è astratta\\
		\hline
			static		&	indica se la variabile è statica	&	-	&	indica se la funzione è statica\\
		\hline
			schema		&	indica il tipo della variabile	&	indica il tipo della costante	&	indica il valore di ritorno della funzione. NULL se void\\
		\hline
			name		&	indica il nome della variabile	&	indica il nome della costante	&	indica il nome della funzione\\
		\hline
			oid			&	indica l'ID della variabile	&	indica l'ID della costante	&	indica l'ID della funzione\\
		\hline
			local environment	&	-	&	-	& indica un puntatore ad una tabella delle variabili locali della funzione\\
		\hline
		\hline
			vararg		&	-	&	-	&	indica il numero di parametri formali della funzione\\
			prototype	&	-	&	-	&	indica un puntatore ai parametri formali della funzione/valore di ritorno\\
		\hline
	\end{tabular}
	\caption{tabelle delle informazioni sensate per ogni risorsa di una classe}
\end{table}

Per quanto riguarda il caso in cui la risorsa è una funzione vararg, local environment e protoype sono
indispensabili per la corretta definizione della funzione stessa. In local Environment sono incapsulati elementi che
possiedono i seguenti campi:
\begin{itemize}
  \item schema: tipo della variabile;
  \item oid: TODO ci andrà veramente qua???
  \item name: indica il nome della variabile;
  \item mode: specifica se si tratta di REAL o COPY;
\end{itemize}
Per quanto riguarda il valore di ritorno \emph{schema} non è sufficiente a descriverlo:
infatti rimane da capire se il valore di ritorno è \emph{real} oppure solo \emph{copy}. Per questo, in prototype, il primo
elemento non è il primo parametro formale della funzione, bensì il valore di ritorno. In questo scenario vararg varrà $i$ ma l'array prototype
sarà lungo $i+1$.\\
La struttura del Local Environment incapsula dunque:
\begin{enumerate}
  \item valore di ritorno: il campo name qui è ignorato;
  \item parametri formali;
  \item variabili locali: il campo mode qui è ignorato;
\end{enumerate}
il campo name di un valore di ritorno può essere qualunque cosa. Per convenzione
si inserisce in tale slot di memoria il carattere ``\0'', valore non
accettabile normalmente come nome di identificatore.

Prototype è una lista che punta ad alcuni degli elementi presenti in Local Environment, diminuendo in questo modo lo spreco di memoria.


\section{Rappresentazione dello schema di una risorsa all'interno della Symbol table}

Un identificatore ha un tipo. Il tipo viene specificato dallo schema proposto nella Symbol Table: in questo modo è possibile sapere per ogni
variabile o costante il relativo tipo per poter effettuare il \emph{type checking}. Un identificatore può in generale avere vari tipi:
\begin{itemize}
  \item tipo semplice: rientrano in questa categoria i tipi INT, CHAR, STRING, BOOL e FLOAT;
  \item tipo array: rientrano nella categoria gli array. Una variabile di questo tipo dovrà poi specificare lo schema del tipo incapsulato in ogni cella dell'array;
  \item tipo classe: rientrano nella categoria qualunque identificatore che sia un'istanza di una classe. Lo schema qui dovrà specificare il CID della classe;
\end{itemize}

Secondo queste specifiche lo schema di un identificatore è una struttura di vari campi:
\begin{itemize}
  \item class: indica se lo schema è di tipo semplice, array o classe;
  \item cid: indica il CID della classe, se presente. Se assente il campo vale -1;
  \item length: indica la lunghezza dell'array, se presente. Se assente il campo vale -1;
  \item arraytype: indica un puntatore ad uno schema che rappresenta il tipo delle celle dell'array, se presente. Se assente il campo vale NULL;
\end{itemize}

Uno schema composto in questo modo lavora in modo ricorsivo in modo che sia possibile incapsulare un numero indeterminato di volte gli array: questo
permette di implementare gli array multidimensionali.

\section{I pacchetti \emph{TNT}}

I pacchetti TNT sono degli agglomerati di classi con un scopo ben preciso, ossia quello di realizzare una particolare missione determinata dal programmatore.
Nei pacchetti TNT troviamo alcuni file:
\begin{enumerate}
  \item il file .kst (Kaboom Symbol Table) che rappresenta la symbol table relativa a tutte le classi nel pacchetto;
  \item il file .klt (Kaboom Label Table) che rappresenta la tabella contenente tutte le label utilizzate dal pacchetto;
  \item i file .kcf (Kaboom Compiled File) che rappresenta le classi precompilate del pacchetto TODO capire meglio come si integrano con l'intermediate code
  \item opzionalmente altri pacchetti TNT
  \item qualunque tipo di file richiesto dalle classe (che sia txt o jpg non fa differenza); 
  \item opzionalmente i file .kaboom sorgente;
\end{enumerate}

L'istruzione require può importare una singola classe oppure un intero pacchetto. Se si decide di importar eun intero pacchetto si userà l'intera Symbol Table
offerta dal pacchetto altrimenti si prenderanno solo dalla symbol table le classi richieste e le relative dipendenze.\\
Sul file system i pacchetti TNT non sono altro che cartelle, magari precedentemente compresse tramite zip TODO chiarire meglio.

\chapter{Analisi Grammaticale}

\section{general view}

\program \arrow \labelFile \pipe \classFile\\ 
\labelFile \arrow \labelsDefinitionList\\
\classFile \arrow \requireClause \classDefinition \opengraph \fieldDeclarationSector \methodDeclarationSector \closegraph\\

\section{\labelsDefinitionList}

\labelsDefinitionList \arrow \labelsDefinition \semicolon \labelsDefinitionList \pipe \labelsDefinition \semicolon\\
\labelsDefinition \arrow \labelModifier \idList\\
\labelModifier \arrow \public \pipe \package\\

\section{\requireClause}

\requireClause \arrow \requireList \pipe \eps\\
\requireList \arrow \requireElement \requireList \pipe \requireElement\\
\requireElement \arrow \require \id \semicolon\\

\section{\classDefinition}

\classDefinition \arrow \classModifierList \class \id \additionalClauseList\\
\classModifierList \arrow \classModifierElement \classModifierList \pipe \eps\\
\classModifierElement \arrow \staticCustom \pipe \abstractCustom\\
\additionalClauseList \arrow \additionClause \additionalClauseList \pipe \eps\\
\additionClause \arrow \extendsClause \pipe \modepolicies \pipe \groupMemberClause\\
\extendsClause \arrow \extends \idList \pipe \eps \\ 
\idList \arrow \id \comma \idList \pipe \id\\
\modepolicies \arrow\readpolicies \writepolicies\\
\readpolicies \arrow \readable \by \accessgroup \pipe \eps\\
\writepolicies \arrow \writeable \by \accessgroup \pipe \eps\\
\accessgroup \arrow \accessElement \comma \accessgroup \pipe \accessElement\\
\accessElement \arrow \id \pipe \all \pipe \onlyme \pipe \children\\
\groupMemberClause \arrow \member \of \idList \pipe \eps\\
\classID \arrow \this \pipe \id\\

\section{\type}

\type \arrow \typeModifier \typeValue\\
\typeModifier \arrow \reference \of \pipe \valueCustom \of \pipe \eps\\
\typeValue \arrow \simpletype \pipe \classtype \pipe \arraytype\\
\simpletype \arrow \intCustom \pipe \stringCustom \pipe \bool \pipe \charCustom\\
\classtype \arrow \id\\
\arraytype \arrow \typeValue \openbrake \closebrake\\

\section{\fieldDeclarationSector}

\fieldDeclarationSector \arrow \fieldList \pipe \eps\\
\fieldList \arrow \fieldElement \fieldList \pipe \fieldElement\\
\fieldElement \arrow \fieldModifier \type \id \modepolicies \semicolon\\
\fieldModifier \arrow \static \pipe \const \pipe \eps \\

\section{\methodDeclarationSector}

\methodDeclarationSector \arrow \methodList \pipe \eps\\
\methodList \arrow \methodElement \methodList \pipe \methodElement\\
\methodElement \arrow \methodPrototype \opengraph \methodBody \closegraph\\
\methodPrototype \arrow \methodModifier \function \passMode \returnType \id \openParenthesis \formalParamDeclList \closeParenthesis \modepolicies\\
\returnType \arrow \typeValue \pipe \void\\
\methodModifier \arrow \static \pipe \eps\\
\formalParamDeclList \arrow \paramDecl \comma \formalParamDeclList \pipe \eps\\
\paramDecl \arrow \passMode \typeValue \id \\
\passMode \arrow \real \pipe \copyCustom \pipe \eps \\

\section{\methodBody}

\methodBody \arrow \statlist \pipe \eps\\
\statlist \arrow \stat \semicolon \statlist \pipe \stat\\
\stat \arrow \localVarDefinition \pipe \assignStat \pipe \whileStat \pipe \doWhileStat \pipe \forStat \pipe \ifStat \pipe \switchStat \pipe \continueStat \pipe \breakStat \pipe \returnStat \pipe \procedureCallStat\\
\localVarDefinition \arrow \typeValue \id\\
\assignStat \arrow \leftvar \assignment \expr\\
\leftvar \arrow \classID \pipe \fieldVar \pipe \arrayVar\\
\fieldVar \arrow \leftvar \point \id\\
\arrayVar \arrow \leftvar \openbrake \expr \closebrake \\
\whileStat \arrow \while \openParenthesis \expr \closeParenthesis \doCustom \opengraph \statlist \closegraph \\
\doWhileStat \arrow \doCustom \opengraph \statlist \closegraph \while \openParenthesis \expr \closeParenthesis\\
\forStat \arrow \for \assignStat \toCustom \expr \doCustom \opengraph \statlist \closegraph\\
\ifStat \arrow \ifCustom \openParenthesis \expr \closeParenthesis \then \opengraph \statlist \closegraph \elseifStatList \elseStat\\
\elseifStatList \arrow \elsifStat \elseifStatList \pipe \eps\\ 
\elsifStat \arrow \elsif \openParenthesis \expr \closeParenthesis \then \opengraph \statlist \closegraph\\
\elseStat \arrow \elseCustom \opengraph \statlist \closegraph \pipe \eps\\
\switchStat \arrow \switch \openParenthesis \expr \closeParenthesis \opengraph \switchList \closegraph\\
\switchList \arrow \caseClauseList \defaultClause\\
\caseClauseList \arrow \caseClause \caseClauseList \pipe \caseClause\\
\caseClause \arrow \case \numconst \colonCustom \opengraph \statlist \closegraph\\
\defaultClause \arrow \default \colonCustom \opengraph \statlist \closegraph \pipe \eps\\
\continueStat \arrow \continue\\
\breakStat \arrow \breakCustom\\
\returnStat \arrow \return \expr\\
\procedureCallStat \arrow \classID \point \procedureCallStat \pipe \id \openParenthesis \actualParamList \closeParenthesis\\
\actualParamList \arrow \paramList \pipe \eps\\
\paramList \arrow \expr \comma \paramList \pipe \expr\\
\newInstance \arrow \new \id \instanceMode\\
\instanceMode \arrow \openParenthesis \actualParamList \closeParenthesis \pipe \bracesList \\
\bracesList \arrow \bracesElement \bracesList \pipe \bracesElement\\
\bracesElement \arrow \openbrake \numconst \closebrake\\

\section{expression associativity}

\expr \arrow \compareExpr\\
\compareExpr \arrow \logicExpr \compareOperator \logicExpr \pipe \logicExpr\\
\compareOperator \arrow \gtCustom \pipe \ltCustom \pipe \geqCustom \pipe \leqCustom \pipe \eqCustom \pipe \neCustom\\
\logicExpr \arrow \logicExpr \logicOperator \mathTopExpr \pipe \mathTopExpr\\
\logicOperator \arrow \andCustom \pipe \orCustom \\
\mathTopExpr \arrow \mathTopExpr \mathTopOperator \mathBottomExpr \pipe \mathBottomExpr\\
\mathTopOperator \arrow \plus \pipe \minus\\
\mathBottomExpr \arrow \mathBottomExpr \mathBottomOperator \termExpr \pipe \termExpr\\
\mathBottomOperator \arrow \timesCustom \pipe \divideCustom \pipe \remainder\\
\termExpr \arrow \procedureCallStat \pipe \leftvar \pipe \constantCustom \pipe \newInstance \pipe \openParenthesis \expr \closeParenthesis\\ 
\constantCustom \arrow \numconst \pipe \stringConst \pipe \boolConst \pipe \charConst\\

\chapter{Analisi Sintattica}

\section{Il SyntaxNode}

L'analisi sintattica si occupa di disporre vari nodi all'interno di un albero, denominato albero
sintattico. I nodi al suo interno possono rappresentare dei \emph{terminali} (ovvero dei nodi foglia) o dei \emph{non terminali} (ossia dei nodi interni
all'albero ) delle definizioni regolari generanti la sintassi del linguaggio.\\
In \emph{Yaoola} l'albero sintattico è formato da vari nodi di tipo SyntaxNode.
Ogni SyntaxNode possiede:
\begin{itemize}
  \item un \textbf{type}: indica che cosa esattamente rappresenta questo nodo; se
  rappresenta un costante intera, un ciclo for oppure un assegnamento;
  \item un \textbf{value}: indica il valore del nodo. Non tutti i nodi possiedono un
  valore. Un esempio di valore potrebbe essere il valore di un nodo costante
  intero (come 5) oppure il tipo di operazione di un nodo (come somma o
  prodotto);
  \item un SyntaxNode \textbf{child}: indica il figlio di questo nodo. Utile per
  navigare nell'albero sintattico;
  \item un SyntaxNode \textbf{brother}: indica il fratello di questo nodo. Utile per
  navigare nell'albero sintattico;
\end{itemize}

i SyntaxNode child e brother permettono di realizzare l'albero vero e proprio, partendo dal nodo comune a tutti gli altri, il nodo radice.
L'albero realizzato è un albero binario in quanto tutti i nodi possono avere al massimo due archi discendenti, o un figlio o un fratello;
vale tuttavia la proprietà di transitività tra fratelli, ovvero il fratello di mio fratello è ancora mio fratello.

\section{tipi di file sorgente}

Per comodità \emph{Yaoola} può leggere due diversi tipi di file sorgente, ognuno esprimente un concetto diverso:
\begin{enumerate}
  \item una \classFile, ossia un file specificante una classe;
  \item un \labelFile, ossia un file specificante gruppi di permessi;
\end{enumerate}

\section{Perché utilizzare una EBNF?}
L'albero sintattico di \emph{Yaoola} viene rappresentato tramite una EBNF.
In verità l'albero sintattico poteva benissimo essere espresso in tre differenti modi. Consideriamo questo esempio, riproducente una group-labels-definition (vedi sezione \ref{sec:group-label-file}):
\begin{lstlisting}
	public ciao,studenti, ospite;
	package get,set, accessibilta;
	package nil;
\end{lstlisting}
La sintassi può essere racchiusa in 3 diversi alberi:
\begin{enumerate}
  \item albero BNF;
  \item albero EBNF;
  \item albero EBNF compresso;
\end{enumerate}
\begin{table}
	\centering
	\begin{tabular}{c}
		\includegraphics[scale=0.25]{../grp/labelFile01.jpg}\\
		\includegraphics[scale=0.25]{../grp/labelFile02.jpg}\\
		\includegraphics[scale=0.25]{../grp/labelFile03.jpg}\\
	\end{tabular}
\end{table}

Tutti e 3 gli alberi hanno lo stesso potere illustrativo; tuttavia  l'albero BNF è molto più esteso di quello EBNF (perdendo dunque in memoria).
La scelta circa quale albero sia il migliore per la rappresentazione fisica del codice sorgente è tra l'albero EBNF e quello compresso. L'albero compresso
è sicuramente più piccolo rispetto a quello EBNF, tuttavia ciò rende più complessa la sua elaborazione da parte dell'analisi semantica e del generatore di codice:
infatti la lista di ID avviene in entrambi gli albero ma mentre in quello EBNF è ben introdotto da un nodo ``id-list'' (rendendo più semplice il switch nell'analizzatore semantico),
l'albero compresso non lo possiede. Per effettuare l'analisi semantica quindi occorrerebbe generare dei casi particolari
\footnote{per la id-list servirebbe che nel nodo di tipo label si leggessero tutti gli ID fratelli e li si incamerasse in una struttura. Nell'albero EBNF semplice, invece
sarebbe possibile inserire un parametro formale della funzione sem() per infdicare quando un ID è una label e quando non lo è: in questo modo la funzione sem() risulterebbe
perlomeno più chiara.} 
che rendono più complesso il codice e quindi più passibile a bug. 

\section{group-label-file}\label{sec:group-label-file}

Per quanto riguarda il \labelFile, esso è un file abbastanza semplice. Vediamone un esempio:

\begin{lstlisting}
	public ciao,studenti, ospite;
	package get,set, accessibilta;
	package nil;
\end{lstlisting}

\section{class-file}\label{sec:class-file}


\chapter{Analisi semantica}

\section{Analisi semantica nel label file}

Nei label file l'analisi semantica è molto semplice, anche perché la grammatica
è molto più semplice.
\begin{itemize}
  \item i modificatori accettati sono solo \public e \package;
  \item due label non possono avere lo stesso nome;
\end{itemize}


attribute grammar:
\begin{itemize}
  \item modifiertype indica il tipo del modifier letto
  \item modifiertypelist indica una lista di tipi di modifiers
  \item namelist indica una lista di nomi
  \item name indica un nome
  \item mode indica se stiamo dichiarando una risorsa (declare) oppure se la voglia usare (usage). Questo attributo serve per capire, ad esempio,
  	se in una id-list dobbiamo verificare se gli ID sono presenti o meno nella symbol table;
\end{itemize}

A=modifiertype
\begin{table}[h]
	\centering
	\label{Tabella semantica}
	\begin{tabular}{|c|l|}
		program \arrow group\_label\_file & 
		\begin{lstlisting}
			nothing
		\end{lstlisting}\\
 		\arrow class\_file & \\
		
		group_label_file \arrow group_labels_definition_list &
		\begin{lstlisting}
			nothing
		\end{lstlisting}\\
		
		class_file \arrow require_sector class_definition '{' field_declaration_sector method_declaration_sector '}' group_label_file \arrow group_labels_definition_list & \\
 
		group_labels_definition_list \arrow group_labels_definition ';' group_labels_definition_list & \\ 
 		\arrow group_labels_definition ';' & \\

		group_labels_definition \arrow modifier_element id_list & 
		\begin{lstlisting}
		
		\end{lstlisting}\\

		id\_list\_1 \arrow TOKEN\_ID ',' id\_list\_2 &
		\begin{lstlisting}
			if (TOKEN_ID.value IN id_list_2.namelist){
				error("");
				id_list_1.namelist=
			}
		\end{lstlisting}\\
 		\arrow TOKEN\_ID &
 		\begin{lstlisting}
 			if (id_list.mode==declare){
 				if (lookup()!=NULL){
 					error id già dichiarato
 				}
 			}else{
 			}
 			id_list.namelist={TOKEN_ID.value}
 		\end{lstlisting}\\

		modifier\_sector \arrow modifier\_list & 
		\begin{lstlisting}
			modifier_sector.modifiertypelist=modifier_list.modifiertypelist
		\end{lstlisting}\\
 		\arrow & 
 		\begin{lstlisting}
 			modifier_sector.modifiertypelist={}
 		\end{lstlisting}\\

		modifier\_list\_1 \arrow modifier\_element modifier\_list_2 & 
		\begin{lstlisting}
			if (modifier_element.modifiertype NOT IN modifier_list_2.modifierlist){
				modifer_list_1.modifierlist=modifier_element.modifiertype U modifier_list_2.modifierlist; 
			}
		\end{lstlisting}\\
 		\arrow modifier\_element &
 		\begin{lstlisting}
 			modifier_list.modifiertypelist={modifier_element.modifiertype};
 		\end{lstlisting}\\

		modifier\_element \arrow TOKEN\_ABSTRACT & 
		\begin{lstlisting}
			modifier_element.modifiertype=abstract
		\end{lstlisting}\\ 
 		\arrow TOKEN\_STATIC & 
 		\begin{lstlisting}
 			modifier_element.modifiertype=static
 		\end{lstlisting}\\
 		\arrow TOKEN\_CONST &
 		\begin{lstlisting} 
 			modifier_element.modifiertype=const
 		\end{lstlisting}\\
 		\arrow TOKEN\_REFERENCE TOKEN\_OF & 
 		\begin{lstlisting}
 			modifier_element.modifiertype=reference
 		\end{lstlisting}\\
 		\arrow TOKEN\_VALUE TOKEN\_OF & 
 		\begin{lstlisting}
 			modifier_element.modifiertype=value
 		\end{lstlisting}\\
 		\arrow TOKEN\_PUBLIC & 
 		\begin{lstlisting}
 			modifier_element.modifiertype=public
 		\end{lstlisting}\\
 		\arrow TOKEN\_PACKAGE & 
 		\begin{lstlisting}
 			modifier_element.modifiertype=package
 		\end{lstlisting}\\
 		\arrow TOKEN\_REAL & 
 		\begin{lstlisting}
 			modifier_element.modifiertype=real
 		\end{lstlisting}\\
 		\arrow TOKEN\_COPY & 
 		\begin{lstlisting}
 			modifier_element.modifiertype=copy
 		\end{lstlisting}\\

		mode_policies_sector \arrow read_policies write_policies
 		\arrow read_policies
 		\arrow write_policies
 		\arrow

		read_policies \arrow TOKEN_READABLE TOKEN_BY access_group_list
		
		write_policies \arrow TOKEN_WRITEABLE TOKEN_BY access_group_list
		
		access_group_list \arrow access_group_element ',' access_group_list
 		\arrow access_group_element

		access_group_element \arrow TOKEN_ID
 		\arrow TOKEN_ALL
 		\arrow TOKEN_ONLYME
 		\arrow TOKEN_CHILDREN
 
		type \arrow simple_type
 		\arrow class_type
 		\arrow array_type
		
		simple_type \arrow TOKEN_INT
 		\arrow TOKEN_STRING
 		\arrow TOKEN_BOOL
 		\arrow TOKEN_CHAR 
		
		class_type \arrow TOKEN_ID
	
		array_type \arrow TOKEN_INTCONST
	
		require_sector \arrow require_list
 		\arrow

		require_list \arrow require_element require_list
 		\arrow require_element
		
		require_element \arrow TOKEN_REQUIRE TOKEN_ID 
 
		field_declaration_sector \arrow field_list
 		\arrow

		field_list \arrow field_element field_list
 		\arrow field_element

		field_element \arrow modifier_sector type TOKEN_ID
	
		method_declaration_sector \arrow method_list
 		\arrow

		method_list \arrow method method_list
 		\arrow method

		method \arrow TOKEN_FUNCTION modifier_sector pass_mode return_type TOKEN_ID

		return_type \arrow type
 		\arrow TOKEN_VOID

		formal_param_declaration_sector \arrow formal_param_declaration_list
 		\arrow

		formal_param_declaration_list \arrow formal_param_declaration ',' formal_param_declaration_list
 		\arrow formal_param_declaration

		formal_param_declaration \arrow pass_mode type TOKEN_ID

		pass_mode \arrow TOKEN_REAL
 		\arrow TOKEN_COPY
 		\arrow

		actual_param_list \arrow param_list
 		\arrow

		param_list \arrow expr ',' param_list
 		\arrow expr
 
		left_hand_side \arrow TOKEN_THIS
 		\arrow TOKEN_ID
 		\arrow field_var
 		\arrow array_var
 		\arrow procedure_call

		field_var \arrow left_hand_side '.' TOKEN_ID
	
		procedure_call \arrow left_hand_side '.' TOKEN_ID
 		\arrow TOKEN_ID

		array_var \arrow left_hand_side '$\[$' expr '$\]$'
 
		new_instance \arrow TOKEN_NEW type

		instance_mode \arrow '(' actual_param_list ')'
 		\arrow braces_list

		braces_list \arrow braces_element braces_list
 		\arrow braces_element

		braces_element \arrow '$\[$' TOKEN_INTCONST '$\]$'
 
		expr \arrow compare_expr

		inner_expr \arrow compare_expr

		compare_expr \arrow logic_expr compare_operator logic_expr
 		\arrow logic_expr

		compare_operator \arrow '>'
 		\arrow '<'
 		\arrow TOKEN_GEQ
 		\arrow TOKEN_LEQ
 		\arrow TOKEN_EQ
 		\arrow TOKEN_NE

		logic_expr \arrow logic_expr logic_operator math_expr_1
 		\arrow math_expr_1

		logic_operator \arrow TOKEN_AND
 		\arrow TOKEN_OR

		math_expr_1 \arrow math_expr_1 '+' math_expr_2
 		\arrow math_expr_1 '-' math_expr_2
 		\arrow math_expr_2

		math_expr_2 \arrow math_expr_2 '*' term_expr
 		\arrow math_expr_2 '/' term_expr
 		\arrow math_expr_2 '\%' term_expr
 		\arrow term_expr

		term_expr \arrow left_hand_side
 		\arrow '!' term_expr
 		\arrow constant
 		\arrow new_instance
 		\arrow '(' inner_expr ')'

		constant \arrow TOKEN_INTCONST
 		\arrow TOKEN_STRINGCONST
 		\arrow TOKEN_BOOLCONST
 		\arrow TOKEN_CHARCONST
 
		class_definition \arrow TOKEN_CLASS modifier_sector TOKEN_ID
		
		additional_clauses_sector \arrow additional_clause_list
 		\arrow

		additional_clause_list \arrow additional_clause additional_clause_list
 		\arrow additional_clause

		additional_clause \arrow extends_clause
 		\arrow group_member_clause

		extends_clause \arrow TOKEN_EXTENDS id_list

		group_member_clause \arrow TOKEN_MEMBER TOKEN_OF id_list

		stat_sector \arrow stat_list
 		\arrow

		stat_list \arrow stat stat_list
 		\arrow stat

		stat \arrow procedure_call ';'
 		\arrow local_variable ';'
 		\arrow assign_stat ';'
 		\arrow while_stat
 		\arrow do_while_stat ';'
 		\arrow for_stat
 		\arrow if_stat
 		\arrow switch_stat
 		\arrow continue_stat ';'
 		\arrow break_stat ';'
 		\arrow return_stat ';'

		local_variable \arrow TOKEN_VAR type TOKEN_ID

		assign_stat \arrow left_hand_side '=' expr
		
		while_stat \arrow TOKEN_WHILE '(' expr ')' TOKEN_DO '{' stat_sector '}'
		
		do_while_stat \arrow TOKEN_DO '{' stat_sector '}' TOKEN_WHILE '(' expr ')'

		for_stat \arrow TOKEN_FOR assign_stat TOKEN_TO expr TOKEN_DO '{' stat_sector '}'

		if_stat \arrow TOKEN_IF '(' expr ')' TOKEN_THEN '{' stat_sector '}' elsif_else_stat_sector

		elsif_else_stat_sector \arrow elsif_else_stat_list
 		\arrow

		elsif_else_stat_list \arrow elsif_stat elsif_else_stat_list
 		\arrow elsif_stat
 		\arrow else_stat

		elsif_stat \arrow TOKEN_ELSIF '(' expr ')' TOKEN_THEN '{' stat_sector '}'

		else_stat \arrow TOKEN_ELSE '{' stat_sector default_clause '}'

		switch_stat \arrow TOKEN_SWITCH '(' expr ')' '{' switch_list default_clause '}'

		switch_list \arrow case_clause_list

		case_clause_list \arrow case_clause case_clause_list
 		\arrow case_clause

		case_clause \arrow TOKEN_CASE expr ':' '{' stat_sector '}' 

		default_clause \arrow TOKEN_DEFAULT ':' '{' stat_sector '}'
 		\arrow

		continue_stat \arrow TOKEN_CONTINUE

		break_stat \arrow TOKEN_BREAK

		return_stat \arrow TOKEN_RETURN expr
	\end{tabular}
	
\end{table}

\end{document}
